\documentclass[12pt,a4paper]{article}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[british,swedish]{babel}
\usepackage{amsmath}
\usepackage{ae}
\usepackage{units}
\usepackage{icomma}
\usepackage{color}
\usepackage{graphicx}
\usepackage{bbm}

\begin{document}

\selectlanguage{swedish}

\title{The Adventures of Edmund\\
Utveckling av ett ramverk med prototyp}
\author{Andrea Buchholz \and Joakim Karlsson \and Richard Sundqvist \and Gustav Vidhög}
\date{\today}
\maketitle

\thispagestyle{empty}

\newpage

\tableofcontents

\thispagestyle{empty}

\newpage

\setcounter{page}{1}
\pagenumbering{arabic}

\section{Introuktion}

Detta dokument diskuterar i huvudsak projektets olika delar och motiverar en del av de val vi tagit. Vårt projekt är lite unikt i den meningen att slutprodukten (ramverket) riktar sig till andra programmerare, inte en lekman. Detta reflekteras även i texten som kan bli av en mer teknisk natur än man annars kan vänta sig.

Även ett prototypspel som skall demonstrera vad ramverket förmår ingår i projektet, och en stor del av utvecklingsarbetet planeras gå åt till detta. Projektets fokus är själva ramverket, särskilt i den tillhörande dokumentationen.

\subsection{Syfte}

Detta projekts syfte är tvådelat. Dels ska ett ramverk definieras med vilket utvecklare kan skapa relativt simpla tvådimensionella plattformsspel som hanterar rörliga objekt. Utöver att förse grundläggande struktur för sådana spel innehåller ramverket funktionalitet för detektion samt hantering av kollisioner mellan objekt. Ramverket avses vara så generellt som möjligt, men primärt fokus ligger på plattformsspelgenren.

Dels ska ett prototypplattformsspel som belyser ramverkets funktionalitet utvecklas, riktat till slutanvändare snarare är utvecklare. Detta skall innefatta en huvudkaraktär vilken skall kunna styras med tangentbordet. Karaktären skall påverkas av gravitation och det skall finnas hinder som kan hoppas över samt fiender som skadar karaktären samt objekt som kan ge spelaren speciella egenskaper eller som behöver samlas för att avsluta banan.

\subsection{Bakgrund}

Plattformssspel som genre uppkom i början av 1980-talet och dominerade arkad- och konsolspelmarknaden i ett tjugotal år framöver (GamesRadar, 2010). Populära spelserier som Super Mario Bros och Sonic the Hedgehog har kodifierat genren och kvarstår idag bland de i särklass mest igenkända och omtyckta varumärken som någonsin skapats i spelindustrin. Även idag publiceras ett flertal relativt framgångsrika tvådimensionella plattformsspel varje månad genom plattformar som Steam, även om genren sedan länge förlorat sin marknadsledande status.

\subsection{Avgränsningar}

Ett antal avgränsningar av projektets omfattning har gjorts. Att ramverket endast avses hantera tvådimensionella system är en sådan. Vidare betraktas endast spel för en spelare i taget på en dator, utan hänsyn tagen till möjligheten för implementation av spel för flera spelare på olika datorer på ett nätverk som kommunicerar sinsemellan.

I hanteringen av rörliga objekt behandlas endast stela kroppar som kan translatera men inte rotera. Detta medför en del beteenden i kollisionshanteringen som inte är konsekventa med klassisk stelkroppsmekanik.

\subsection{Disposition}

Rapportens disposition reflekterar projektets tvådelade natur. Det inledande delen syftar till att presentera och inrama projektet. Därefter följer den del som beskriver projektmetodiken och de designprinciper som styrt utvecklingsarbetet. Rapportens huvuddel beskriver en rad viktiga delproblem, med beskrivning av vald lösning och i föreliggande fall redogörelse för teoretiskt underlag. Den avslutande delen presenterar och sammanfattar resultatet, samt diskuterar hur väl projektet uppnått sina mål och vilka möjligheter som finns för vidare utveckling som skulle kunna göra projektet mer fullständigt.

\section{Metod}

\subsection{Iterativ projektmodell}

Projektet har tagits fram genom arbete mot en agil iterativ processmodell bestående av fyra olika faser. Iterativ utveckling är en strategi där tids avsätts för att revidera och förbättra delar av systemet, motsatsen vore att planera upp hela projektet för att få en korrekt fungerande produkt vid första försöket. (Cockburn, 2008) I praktiken innebär det att man snabbt implementerar en första version av en funktionalitet och sedan utvärderar den för att upptäcka problem eller förbättringar. 

De två första faserna fokuserar på själva modellerandet av produkten och de senare på implementationen av modellen. Under fas 1, ''Requirement elicitation'' (kravspecifikation), så samlas funktionalitetskrav in från den tänkta kunden, här simulerat av gruppen själv, tillsammans med kundens förväntningar på de specifika funktionaliteterna (von Hacht, 2014). Detta sammanställs sedan till ''Use cases'' som används under nästa fas; ''Analysen''.

Under analysfasen beskrivs, med hjälp av UML-klassdiagram och sekvensdiagram, hur de krav som fångades upp under kravspecifikationen skall implementeras i vår produkt. Under de återstående faserna ''Design'' samt ''Implementation'' så implementeras en första version av vår ''Analysmodell'' vilken vi sedan iterativt reviderar och lägger till ny funktionalitet på.

Den iterativa arbetsmodellen appliceras alltså inte enbart över implementationsfaserna utan även Analysmodellen revideras och utvidgas under dess framtagande.

\subsection{Test-Driven Development}

Utvecklingsarbetet har skett efter en variant av systemutvecklingsmodellen ''Test-Driven Development'', TDD, vilken är en utvecklingsmetod med stort fokus på tre tätt knutna aspekter av utvecklingen; programmering, testning och design/refaktorering. (Agile Alliance, 2013)

Den stora skillnaden mot utveckling som inte är driven av testning är att innan en ny funktionalitet implementeras så måste först ett enhetstest skrivas. Enhetstest är ett test som testar den minsta möjliga komponenten i ett system. Detta test kommer ej att godkännas för tillfället men skall bli godkänt då den tänkta funktionaliteten är implementerad. Efter det att testet är skrivet så implementeras funktionaliteten på enklast möjliga vis för att sedan refaktoreras för att ta bort duplicering av kod och skriva så elegant kod som möjligt vilken klarar av testets krav. Genom att upprepa denna cykel så skrivs ny kod enbart då ett automatisk test har misslyckats och upprepning av kod elimineras. (Beck, 2002)

Denna arbetsgång har följts till den mån projektets begränsade tid har erbjudit, annars har tester skrivits parallellt med utvecklingsarbetet för att alltid ha en bra täckning på enhetstesten.

En testsvit för hela projektet kör alla enhetstest och på så vis kan man upptäcka om en nyimplementerad funktionalitet gör ett annat test icke godkänt och på så vis finna oönskade kopplingar finns mellan olika delsystem i modellen. Detta möjliggör för utvecklingslaget att arbeta parallellt med olika uppgifter utan att införa problem för varandra.

\subsection{Språk och externa bibliotek}

Källkoden är uteslutande skriven i Java Standard Edition 1.7, ett objektorienterat plattformsoberoende programspråk, för att kunna köras på såväl Windows, Mac och Unixplattformar. Då projektets huvudsakliga syfte är att från grunden skapa ett ramverk med vilket avändare skall kunna skapa enkla tvådimensionella plattformsspel har användandet av externa bibliotek valts bort och endast Javas standardbibliotek används.

\subsection{Versionshantering}

Versionshantering sköts uteslutande i Git, en lösning med god prestanda (Git, 2014) och funktionalitet som tillåter riskfri experimentation i nya ''brancher''. Git fritt tillgängligt under GNU-licens.

Projektfilerna hostas på Google Projects:
https://code.google.com/p/tda367/

\section{Teori}

\subsection{Model-View-Control}

Ramverket är konstruerat enligt designmönstret Model-View-Control (hädanefter MVC) för att hålla isär modell- och presentationskod. Förhoppningen är att nyttjandet av känd arkitektur ska göra det enklare för nya användare att sätta sig in i hur ramverket används och fungerar.

\subsection{Uppdateringsloop}

En loop används för att driva spelet framåt. I varje iteration körs relevant kod och sedan väntas en konstant tid innan nästa iteration körs. Detta är inte särskilt elegant då exekveringstiden av den koden i allmänhet inte är densamma mellan två iterationer. I praktiken innebär det att ett objekt med en oförändrad hastighet i ramverket kunna röra sig med varierande hastighet över skärmen.

\subsection{Objekt och kollisionshantering}

Objekt i ramverket representeras av klassen GameObject, som väsentligen består av två delar: En grafisk representation i form av en textur, klassen Texture, och en fysisk representation i form av en polygon, klassen Hitbox. Vidare ligger ett objekt i ett lager, representerat av klassen Layer, vilket beskriver vilka andra objekt, om några, objektet kan kollidera med.

Funktionalitet för förflyttning av objekt samt detektion och hantering av kollisioner finns i klassen ObjectMover. Objekten flyttas ett i taget, i och med vilket dess position och hastighet uppdateras. Vid kollision ändras hastighet på de kolliderande objekten i en riktning vinkelrät mot den yta som kollideras mot, enligt i traditionell stelkroppsmekanik känt beteende för endimensionell (in-)elastisk kollision. Om kollision inträffar notifieras kolliderande objekt för eventuell ytterligare hantering i spelets logik.

För kollisionshantering används ''separerande axel-metoden'' (Eberly, 2008), som bygger på Separating Axis Theorem, eller mer generellt Hyperplane Separation Theorem. Informellt innebär satsen kortfattat, i två dimensioner, att två konvexa enkelt sammanhängande kompakta mängder inte skär varandra om och endast om det finns en axel sådan att objektens projektion på axeln inte överlappar. Metoden säger vidare för polygoner att endast normaler till polygonernas sidor behöver tas hänsyn till när en sådan axel eftersöks, vilket inses intuitivt men är litet mer komplicerat att bevisa formellt (se bild för exempel på test längs axel, något opedagogiskt dock ej normal till en sådan sida, för två par av polygonkonfigurationer).

% BILD !!!

\subsection{Grafik}

Ramverket har inbyggd hantering av texturer, vilka kan byggas från de flesta bildformat. En Texture är baserad på Java-bibliotekets TexturePaint. Den är i sig mycket enkel, en konstruktor för generering av en Texture med adress till en bildfil som argument samt metoder för skapa translaterade texturer för rörliga objekt.

Lejonparten av grafiken hanteras av View-klassen med dotterklasser, som tillhandahåller metoder för ritning av objekt och dess hitbox. En hitbox är inte menad att ritas ut, men funktionalitet finns ändå för att förenkla felsökning.

Den grafiska representationen av ett objekt tillhandahas av objektet själv, där det är upp till varje objekt att när dess grafiska data efterfrågas avgöra huruvida en textur behöver uppdateras eller ej. Den färdiga metoden som finns i GameObject förutsätter att objektet alltid är i rörelse, vilket är ett önskvärt beteende för de flesta typer av objekt. GameObject tillhandahar även ett stratavärde, vilket avgör om ett objekt renderas över ett annat.

\section{Resultat}

Initialt så var ramverket tänkt vara det primära syftet och att en prototyp skulle skapas för att representera ramverkets funktionalitet. Under arbetets gång fick prototypen en mindre roll än tänkt, då utvecklingen av ramverket tog mer tid än väntat.

\subsection{Ramverk}

Ramverket tillhandahåller majoriteten av den funktionalitet som vi satte upp som mål, om än något otillfredställande i vissa fall. Det lider dessvärre av prestandaproblem, då det flyter bättre på en laptop än på en högpreseterande stationär dator.

\subsubsection{Model-View-Control}

MVC-mönstret har följts i den mån det är möjligt. Det mest slående untantaget är 
kopplingen mellan Control och Model, där användaren väntas låta modellen 
hämta input från tangentbords och mus, snarare än att kontrollern skickar 
kommandon till modellen.

\subsubsection{Uppdateringsloop}

Prestanda bör inte vara ett problem då tvådimensionella spel i regel kan köras smärtfritt på en modern dator. Valet av denna typ av uppdatering motiverades av att vi hellre ville lägge energi på andra, mer intressanta och viktigare delar av ramverket. Huruvida oregelbunden iterationshastighet är ett problem beror huvudsakligen på vad för typ av spel som implementeras.

\subsubsection{Objekt och kollisionshantering}

Kollisionshanteringen har i huvudsak önskad funktionalitet, eventuellt med undantag för möjlighet att förankra ett objekt eller begränsa dess rörlighet till ytan av ett annat (se 5.3.4 och 5.3.5). Kollisionsdetektionen fungerar som väntat, men hanteringen har fortfarande brister i en del speciella fall, där hastigheter efter kollisionen kan bli allt annat än intuitiva.

\subsubsection{Grafik}

Ramverkets grafikhantering klarar de uppgifter den planerades hantera, med 
undantaget bakgrundsmotiv. Ramverket klarar inte av att rita ut stora bilder i realtid, 
istället bjuds observatören på ett bildspel. Detta är ett problem i Swing vi ännu inte 
lyckats lösa.

\subsection{Prototyp}

Funktionaliteten i den prototyp som utvecklats är menad att visa på styrkor som finns i det framtagna ramverket. Detta innefattar först och främst den kollisionshantering som skapats och hur denna appliceras på alla tänkbara kollisioner i prototypen.

\subsubsection{Spelvärlden}

Världen i prototypen är uppbyggd av ett flertal olika objekt med ett antal olika egenskaper, såsom en mark som karaktären rör sig på, en fiende som karaktären blir skadad av, medicin som karaktären samlar ihop för att kunna avsluta en nivå, ett antal mindre objekt som går att flytta på samt även större objekt som är orubbliga.

\subsubsection{Lager}

De olika objekten kan befinna sig i olika lager vilket innebär att specifika objekt kan placeras så de endast interagerar med objekt i ett visst lager. Att hantera dessa olika egenskaper och lager visar tydligt på hanteringen av kollisioner i ramverket, där objekten sedan agerar enligt dess egna specifika spellogik som definieras i prototypen.

\subsubsection{Kontroll av spelaren}

Då prototypen skall ha en stark koppling till traditionella tvådimensionella plattformsspel så finns det vissa tydliga avgränsningar i karaktärens rörelsemönster. Påverkan av gravitation är en sådan egenskap och att endast kunna hoppa när karaktären befinner sig på en yta.

\section{Diskussion och slutsats}

\subsection{Diskussion}

Då vi i föregående kurser mest gjort turbaserade spel utifrån ett tilldelat ramverk så kände vi alla att vi ville ha en större utmaning. Valet föll snabbt på ett realtidsspel och då gruppen ville lära sig Java bättre så valde vi att enbart använda oss av dess standardbibliotek. Eftersom vi visste att vi inte skulle kunna, eller hinna, göra ett lika komplett eller bra spel som om vi använde oss av redan skrivna fysik- och grafikmotorer så lades fokus på ramverket. 

Eftersom att skapa ett ramverk var ett större projekt än vi kunnat ana, så fick vi under projektets gång göra avgränsningar som vi tidigt i projektet inte räknat med.

Då prototypen fick mindre tid än väntat så fick vissa avgränsningar göras i vad som slutligen skulle finnas med i prototypen. Ursprungligen var planen att dela upp arbetet på både ramverket och prototypen men då ramverket slukade allt mer tid så slopades planerna på att skapa en grafiskt tilltalande spelvärld med god spelupplevelse. Istället fokuserade vi på att skapa ett simpelt spel som visar på ramverkets styrkor vilket gjorde att ett aktivt val togs att viss funktionalitet som ej ännu tillfredställer våra krav ej inkluderades i prototypen.

Diskrepansen mellan förväntad och verklig grafikprestanda kan förklaras av att vi använder Swing på ett sätt som det inte är gjort för, då det i huvudsak bör användas för att rita ut grafiska gränssnitt. Det går antagligen att lösa även med Swing, givet utökad utvecklingstid.

\subsection{Slutsats}

Vårt ramverk har grundläggande funktionalitet för skapandet av ett simpelt tvådimensionellt plattformsspel, men det finns fortfarande många sätt som det kan vidareutvecklas på. Prototypen demonstrerar både den funktionalitet vi lyckats med men lyser även ett ljus på den funktionalitet som vi saknar. En del av denna funktionalitet har lagts en grund för men har haft en viss problematik, medan annan funktionalitet inte har hunnits med.

Eftersom objektens fysiska egenskaper kan sättas fritt går det enkelt att åstadkomma underhållande spelmekanik som bryter mot vad som är fysiskt möjligt. Med hjälp av detta kan man skapa en stor variation av olika sorters spel. Det är lätt att skapa en spelnivå där spelfysiken kan bero på en given plats i nivån. Exempelvis kan man låta spelarkaraktärens elasticitet eller vikt bero på vart i spelvärlden man befinner sig och på samma sätt variera gravitationen.

\subsection{Fortsatt utveckling}

Ett program av den här typen är aldrig färdigt. Nedan följer några av de förbättringar vi vidare skulle vilja implementera.

\subsubsection{Normaliserad hastighet}

Hastighet i ramverket definerad som för flyttning ett givet antal punker i (x, y)-led per iteration. Vi skulle vilja definiera den som förflyttning en given fraktion av fönstrets höjd och bredd per vald tidsperiod.

\subsubsection{Skalning}

I dagsläget visas endast mer eller mindre av spelvärlden när fönsterstorleken ändras.
Vi önskar implementera skalning av grafiken för att ge en konsistent upplevelse på 
olika datorer.

\subsubsection{Spelfunktionalitet för objekt}

För att göra ramverket mer lättillgängligt och lockande så hade vi velat erbjuda ett antal objekt med, inom traditionella plattformsspel, vanligt förekommande beteenden och attribut. Dessa skulle kunna tillhandahålla standardbeteenden som extra liv och skadliga eller hjälpsamma objekt.

\subsubsection{Förflyttning längs given väg}

Rörelse uppför backar orsakar idag hundratals kollisioner, när det över huvud taget fungerar. Vi skulle vilja göra det möjligt för ett objekt att följa en godtyckling, fördefinierad väg utan att kollidera med marken.

\subsubsection{Förankrade objekt}

En typ av objekt vars position är beroende av ett ankare (rimligtvis ett annat objekt) är idag inte möjligt utan att skriva över ett stort antal metoder i GameObject. Detta skulle kunna utnyttjas när det är intressant att veta vilken del av ett objekt som kolliderar.

\newpage

\section*{Källor}

Beck, Kent (2002): Test Driven Development (Three Rivers Institute)
Agile Alliance (2013):
http://guide.agilealliance.org/guide/tdd.html [2014-05-05]
Cockburn, Alistar (2008):
http://www.crosstalkonline.org/storage/issue-archives/2008/200805/200805-Cockburn.pdf [2014-05-02]
Eberly, David (2008):
http://geometrictools.com/Documentation/MethodOfSeparatingAxes.pdf [2014-05-23]
GamesRadar (2010):
Gaming's most important evolutions,
http://www.gamesradar.com/gamings-most-important-evolutions/ [2014-05-23]
von Hacht, Joachim (2014):
http://www.cse.chalmers.se/edu/course/TDA367/lect/2_requirement_elicitation.pdf [2014-05-23]
Git (2014):
http://git-scm.com/about [2014-05-23]

\end{document}
